According to a service-oriented architecture, a backend service layer provides services (i.e., business functionality) to service consumers, typically via Web protocols. FIG. 1 is a block diagram illustrating one such scenario. Typical service consumers use this business functionality to provide user interfaces, application-to-application or business-to-business integration, output management (e.g., printing), spreadsheet download, etc. Service consumers of different types, or even of a same type, may access the backend service layer in different ways. Therefore, the services are not particularly adapted to the requirements of any particular service consumer.
One such service consumer may comprise a user interface client application. A user interface client application may conform to a data model which is suited to implementation of a user interface. For example, the data model may define various UI elements, such as drop-down menus, trees, and fact sheets. A developer adds these UI elements to screen layout patterns and binds the elements to entities of the backend service layer, and then develops user interface logic (e.g., logic for computing user interface indicators or coloring/hiding fields) in terms of the user interface data model.
The entities of the backend service layer to which the UI elements are bound are business objects, which expose their data in a complex, normalized data tree consisting of nodes containing attributes, actions (i.e., executing business logic on a node) and associations to other nodes. Data for a UI element which is bound to a business object is retrieved based on the associated nodes of the business object.
FIG. 2 illustrates the above-mentioned binding and association. The List Node element of the UI component model is populated with data from the Item element of business object A, and the Structure A element of the UI component model is populated with data from the Sub-Item A node of business object A. For each main business object node referenced by a UI component data model, a corresponding runtime business object node implementation exists. This implementation executes changes on the corresponding node but also retrieves the node's data based upon change notifications or explicit read requests.
Data retrieval service calls are therefore organized alongside a complex tree of business object nodes. In order to traverse the node tree, a retrieval mechanism relies on modeled associations between different business object nodes, especially when nodes of other business objects are joined into the tree. For example, if a UI component model binds to an Item node of business object A and to an Item node of business object B, a cross-BO business object association from business object A Item to business object B Item must exist to ensure proper data retrieval.
FIG. 3 illustrates a cross-BO business object association as modeled within the business objects themselves. The association relies on a modeled foreign key (e.g., Item node of business object A contains a key attribute of Item node of business object B or vice versa). Accordingly, when such an association is used to read data, the backend service layer will use the foreign key information in order to load the Item node of business object B based upon the Item node of business object A.
As also illustrated in FIG. 3, intra-business object associations may similarly define a link from a parent business object node to a sub-node having a dedicated role.
More specifically, if a 0 . . . n sub-node can contain one instance with a specific role, its parent node may directly link to this instance via a dedicated association representing the role's semantic. In one example, an Item node contains an ItemParty node which in turn may include party instances of different types (e.g., Supplier, Account, . . . ). If the parent node needs to link to one particular party instance, an intra-business object association which represents the role is created in the business object metadata. When this association is followed during data retrieval, the service layer will only return the relevant instance, if it exists.
Not all intra- or cross-business object associations are modeled. For example, a node of business object A might link to n different business objects and nodes, depending on its foreign key and the type information. All possible associations are not modeled because such an approach would quickly overwhelm the governing model. In another instance, an association between a node of business object A and a node of business object B may be deemed desirable. However, business object A resides in a lower software logistics layer than business object B and is unaware of the higher layer due to deployment concerns.